Use case
In software and systems engineering, a use case (pronounced /juːs/, a case in the use of a system) is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.
In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual statements.
History
In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying use cases. In 1992 his co-authored book[1] helped to popularize the technique for capturing functional requirements, especially in software development. Originally he used the terms usage scenarios and usage case, which were the more correct translations of the Swedish word "användningsfall" he used, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case.[2] Since Jacobson originated use case modeling many others have contributed to improving this technique, notably including Alistair Cockburn.
Use case structure
Martin Fowler
Martin Fowler states "There is no standard way to write the content of a use case, and different formats work well in different cases."[3]:100 He describes "a common style to use" as follows:[3]:101
- Title: "goal the use case is trying to satisfy")[3]:101
- Main Success Scenario: numbered list of steps[3]:101
- Step: "a simple statement of the interaction between the actor and a system"[3]:101
- Extensions: separately numbered lists, one per Extension[3]:101
- Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.[3]:101
Alistair Cockburn
Alistair Cockburn describes a more detailed structure for a use case, but permits it to be simplified when less detail is needed. His "fully-dressed" use case structure is:[4]:9-10
Fully dressed use case structure
Cockburn's Fully dressed use case template lists the following fields:[5]
- Title: "an active-verb goal phrase that names the goal of the primary actor"[6]
- Primary Actor
- Goal in Context
- Scope
- Level
- Stakeholders and Interests
- Precondition
- Minimal Guarantees
- Success Guarantees
- Trigger
- Main Success Scenario
- Extensions
- Technology & Data Variations List
- Related Information.
In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and goal level.
Cockburn's approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn's "Fully dressed use case" template from software to systems of all kinds, with the following fields differing from Cockburn:[7]
- Variation scenarios "(maybe branching off from and maybe returning to the main scenario)"
- Exceptions "i.e. exception events and their exception-handling scenarios"
Casual use case structure
Cockburn recognizes that projects may not always need detailed "fully-dressed" use cases. He describes a Casual use case with the fields:[8]
- Title (goal)
- Primary Actor
- Scope
- Level
- (Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.
Design scope icon
Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box (internal detail is hidden) or white-box (internal detail is shown). Five symbols are available:[9]
- Organization (black-box), a filled icon of a house
- Organization (white-box), an unfilled icon of a house
- System (black-box), a filled icon of a box
- System (white-box), an unfilled icon of a box
- Component, an icon of a screw or bolt.
Other authors sometimes call use cases at Organization level "Business use cases".[10]
Goal level icon
Cockburn suggests annotating each use case with a symbol to show the "Goal Level";[11] the preferred level is "User-goal" (or colloquially "sea level"[3]:101).
- Very high summary, an icon of a cloud
- Summary, an icon of a flying kite
- User-goal, an icon of waves at sea
- Subfunction, an icon of a fish
- Too low, an icon of a seabed clam-shell.
Actors
A use case defines the interactions between external actors and the system under consideration to accomplish a goal. An actor specifies a role played by a person or thing when interacting with the system.[12] The same person using the system may be represented as different actors because they are playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash, or playing the role of a Bank Teller when using the system to restock the cash drawer.
Types of Actors [13]
- Primary Actor - Fulfills the user goals by using the services of the SuD (System Under Discussion). Ex: 'Cashier' in a Process Sale System.
- Secondary Actor - Provides a service to the SuD. Ex: 'Automated payment authorization service'.
- Offstage Actor - Has an interest in the behavior of the system but is not primary or secondary. Ex: A government tax agency.
Use case notation
In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are represented in a use case diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system block level.
Limitations
Limitations of Use cases include:
- Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
- Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
- Use cases are complex to write and to understand, for both end users and developers.
- As there are no fully standard definitions of use cases, each project must form its own interpretation.
- Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.
- In Agile, simpler user stories are preferred to use cases.
- Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix.
- Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques.[14]
- Use cases are a starting point for test design, [15] but since each test needs its own success criteria, use cases may need to be modified to provide separate postconditions for each path.[16]
See also
References
- ^ Jacobson et al, 1992.
- ^ Alistair Cockburn, "Use cases, ten years later"
- ^ a b c d e f g h Fowler, 2004.
- ^ Cockburn, 2001
- ^ Cockburn, 2001. Page 120.
- ^ Cockburn, 2001. Inside rear cover. Field "Use Case Title".
- ^ Alexander and Beus-Dukic, 2009. Page 121
- ^ Cockburn, 2001. Page 120.
- ^ Cockburn, 2001. Inside front cover. Icons "Design Scope".
- ^ Suzanne Robertson. Scenarios in Requirements Discovery. Chapter 3 in Alexander and Maiden, 2004. Pages 39-59.
- ^ Cockburn, 2001. Inside front cover. Icons "Goal Level".
- ^ http://www.omg.org/docs/formal/07-02-03.pdf §16.3.1
- ^ Applying UML and Patterns: An Introduction to object-oriented Analysis and Design and iterative development ISBN 0137488807
- ^ Bertrand Meyer. Object Oriented Software Construction. (2nd edition). Prentice Hall, 2000.
- ^ Frank Armour and Granville Miller (2000). Advanced Use Case Modeling: Software Systems. Addison-Wesley Professional. ISBN 0201615924.
- ^ Richard Denney (2005). Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley Professional. ISBN 0321316436.
Bibliography
- Alexander I., Maiden N. Scenarios, Stories, Use Cases. Wiley 2004.
- Cockburn, A. Writing Effective Use Cases. Addison-Wesley, 2001.
- Fowler, M. UML Distilled (Third Edition). Addison-Wesley, 2004.
- Jacobson I., Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
External links